Routing system and method for transparently rocovering routing states after a failover or during a software upgrade

ABSTRACT

Methods and apparatus for efficiently enabling routing states to be recovered after a failover or during a software upgrade in a system which supports graceful restart and stateful switchover are disclosed. According to one aspect of the present invention, a method for restarting a network device which has a plurality of routers and is in communication with a first peer being arranged to support graceful restart and a second peer includes performing a graceful restart with respect to the first peer. A peer transparent failover is performed with respect to the second peer. The graceful restart and the peer transparent failover are performed in response to a failure associated with the network device.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates generally to network systems. Moreparticularly, the present invention relates to enabling routers which donot support graceful restart to substantially transparently have theirassociated states recovered on a router which is being restarted andalso performs graceful restart.

2. Description of the Related Art

The demand for data communication services is growing at an explosiverate. Much of the increased demand is due to the fact that moreresidential and business computer users are becoming connected to theInternet. Furthermore, the types of traffic being carried by theInternet are shifting from lower bandwidth applications towards highbandwidth applications which include voice traffic and video traffic.

As the demand for data communication services grows, the use of highavailability networks is increasing. To this end, many networks arebeing built such that the components of the networks, e.g., routers, maycontinue to provide service even when the components must be reset orrestarted. A component may generally be restarted when it has suffered afailure, e.g., a control module failure, or when a software upgrade isin process. In some cases, a graceful restart may be used to restart acomponent substantially while enabling the component to continue tofunction.

Networks generally include a plurality of components or peers which arein communication. FIG. 1 is a diagrammatic representation of a network.A network 100 includes peers 104, e.g., routers or hosts, which are incommunication across connections 108 using a Border Gateway Protocol(BGP) over a Transmission Control Protocol (TCP). Typically, sessionsmay be established using connections 108 such that one peer 104 mayexchange routing information packets with another peer 104, e.g., peer104 a may establish a session with peer 104 b. When peer 104 a suffers afailure, connections 108 a, 108 c, 108 d effectively go down, and peers104 b, 104 d, 104 e may no longer completely trust information that wasreceived from peer 104 a.

When all peers 104 support a BGP Graceful Restart, a graceful restartmay be accomplished to enable traffic to continue to be routed throughpeer 104 a even when peer 104 a has suffered a BGP failure and is in theprocess of restarting. As will be appreciated by those skilled in theart, a graceful restart enables data-forwarding to continue such thatpackets may be processed and forwarded through peer 104 a when BGP onpeer 104 a is being restarted, i.e., even when a portion of peer 104 awhich is responsible for identifying best paths has failed. By way ofexample, when peer 104 a fails, graceful restart enables peers 104 b,104 d, 104 e to wait for peer 104 a to come back online, since althoughpeer 104 a has gone down, after a certain amount of time, peer 104 awill be back online. Peer 104 a effectively requests that peers 104 b,104 d, 104 e not remove any information from peer 104 a.

During a graceful restart, a restarting peer, e.g., peer 104 a, may seta restart bit to indicate that it has restarted, and may set aforwarding state bit to indicate that it has preserved or otherwisemaintain its forwarding state. The preservation of the forwarding stateallows peer 104 a to restart while peers 104 b, 104 d, 104 e maymaintain their routes through peer 104 a. In other words, a gracefulrestart is a substantially transparent process that allows peers 104 b,104 d, 104 e to effectively hide the restart of peer 104 a from the restof network 100 in terms of packet forwarding only.

As previously mentioned, peers 104 may be routers. With reference toFIG. 2, the configuration of routers will be described. A first router202 may be in communication with a second router 206 over an interface210, e.g., a connection. Router 202 has an active route processor 214,and a standby route processor 218. Active route processor 214, or anactive route switch processor, controls and runs routing protocols.Standby route processor 218, or a standby route switch processor, isarranged to take over the functions of active route processor 214 whenactive route processor 214 experiences downtime.

Both active route processor 214 and standby route processor 218 includea BGP speaker 222 and a TCP speaker 226, as will be appreciated by thoseskilled in the art. Active route processor 214 and standby routeprocessor 218 are substantially connected to linecards 232 through a bus230. Linecards 232 are arranged to allow interfaces such as interface210 to enable communication between router 202 and other routers, as forexample router 206, which may include the same internal components asrouter 202, as shown.

As will be understood by those skilled in the art, while the abovedescription of a typical router 202 mentions a separate active routeprocessor and a standby route processor, router 202 may instead includean active stack of BGP and TCP, and a standby stack of TCP and BGP onthe same physical route processor.

If router 202 needs to be restarted and both routers 202, 206 have thecapability to support a graceful restart, then a graceful restart mayoccur such that packet forwarding between router 202 and router 206 mayessentially remain unaffected while the graceful restart occurs. Duringa graceful restart of router 202, router 202 will inform router 206 towait for a certain period of time before removing its associated routesfrom router 202 and allowing packet forwarding to continue. If router202 comes back on line within the certain period of time and if a routeassociated with router 206 is received again, then forwarding for thatassociated prefix is effectively unaffected.

In order for both router 202 and router 206 to support a gracefulrestart, both router 202 and router 206 must support the protocolextensions required by a graceful restart. That is, both router 202 androuter 206 must both be upgraded to have the software that supports agraceful restart. When router 202 and router 206 are both owned by acommon service provider, then ensuring that the relevant software is ofthe same version on both routers 202, 206 may be relatively easy. Evenin such a case, an upgrade may occur at different times. However, whenrouter 202 is owned by a service provider and router 206 is owned by acustomer, for instance, it may be difficult to ensure that both routers202, 206 have the relevant version of the software. In some situations,the relevant software in router 206 may not be upgradeable in the sametime frame as the relevant software in router 202. Further, in othersituations, it may not be possible to upgrade the relevant software inrouter 206. There may also be situations where a service provider doesnot wish to provide any information about internal failures at all.

Some networks use a full stateful switchover solution in which all TCPand BGP states are substantially synchronized on an active routeprocessor and a standby route processor of a router at all times.Stateful switchover generally allows for a standby route processor totake control of a failed active route processor while maintainingconnections which were established by the active route processor, and isone example of a failover method. A failover is generally an operationalmode in which the functions of a component are assumed by standbysubcomponents when active subcomponents become unavailable. Typically,maintaining the connections established by an active route processor isachieved at least in part by checkpointing data needed to maintainconnections and functionality from the active route processor to thestandby route processor. Although the use of a stateful switchoversolution with all peers or routers associated with a router which hassuffered a failure may be useful when graceful restart is not supportedby all peers associated with the failed router, such a solution is notvery scalable, and the cost and performance characteristics associatedwith the solution are often unacceptable.

Therefore, what is needed is a method and an apparatus which allows afailed router to efficiently maintain its functionality during a restartwithin a network when not all peers associated with the failed routersupport graceful restart. That is, what is desired is a system whichallows for a failover to occur with a relatively high level ofperformance within a network that includes peers which do notnecessarily support graceful restart.

SUMMARY OF THE INVENTION

The present invention relates to a system for efficiently enablingrouting states to be recovered after a failover or during a softwareupgrade in a system which supports graceful restart and statefulswitchover. According to one aspect of the present invention, a methodfor restarting a network device which has a plurality of routers and isin communication with a first peer being arranged to support gracefulrestart and a second peer includes performing a graceful restart withrespect to the first peer. A peer transparent failover is performed withrespect to the second peer. The graceful restart and the peertransparent failover are performed in response to a failure associatedwith the network device. In one embodiment, when a first route processorboots up, the method also includes identifying a session between thenetwork device and the second peer as a transparent failover session.

Typically, efficient routing system failover processes require thatparticipating peers in a network have the same software capabilities,i.e, a version of software which supports graceful restart. Sinceservice providers generally do not have control over customer networks,service providers may not synchronize software upgrades or forcesoftware upgrades. By allowing graceful restart to be performed withrespect to peers which are substantially controlled by a serviceprovider and by allowing other transparent failover processes, e.g., astateful switchover, to be performed with respect to peers which are notcontrolled by the service provider, failover processes may be relativelyefficiently executed.

According to another aspect of the present invention, recovering arouting state associated with a network device when the network deviceis reset includes performing a graceful restart with respect to a firstpeer and performing a transparent failover with respect to a secondpeer. The peer transparent failover includes processing an event queuemaintained on a standby route processor of the plurality of routeprocessors to substantially recreate the routing state. Both thegraceful restart and the peer transparent failover are performed whenconnections associated with the network device are reset.

These and other advantages of the present invention will become apparentupon reading the following detailed descriptions and studying thevarious figures of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1 is a diagrammatic representation of a network.

FIG. 2 is a diagrammatic representation of a plurality of routers.

FIG. 3 is a diagrammatic representation of a router which is arranged tosupport both graceful restart and stateful switchover in accordance withan embodiment of the present invention.

FIG. 4 is a diagrammatic representation of a router which is arranged toperform both graceful restart and stateful switchover in accordance withan embodiment of the present invention.

FIG. 5 is a process flow diagram which illustrates the steps associatedwith one method for effectively restarting a router once a failure hasoccurred in accordance with an embodiment of the present invention.

FIG. 6 is a process flow diagram which illustrates the steps associatedwith one method of synchronizing route processors in a router inaccordance with an embodiment of the present invention

FIG. 7 is a diagrammatic representation of a network device suitable forimplementing one embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Many networks include peers which either do not support graceful restartor do not have a current software version that supports gracefulrestart. As a result, it may not be possible to perform a gracefulrestart with respect to substantially all peers associated with a routerwhich has to be restarted or is undergoing a connection reset. When anetwork includes both peers which support graceful restart and peerswhich do not support graceful restart, a full stateful switchoversolution may be used when an associated router needs to be restarted.The use of a full stateful switchover solution is generally not a viableoption as the performance of a full stateful switchover solution isgenerally poor.

Within a network, by allowing peers which support graceful restart to berestarted using graceful restart based failover and by allowing peerswhich do not support graceful restart to undergo a transparent failoversuch as a stateful switchover, the benefits of graceful restart areavailable to graceful restart peers while other peers may use statefulswitchover. Typically, graceful restart may be used for core side peerswhile customer side peers use stateful switchover. A system which allowsfor graceful restart based failovers for core side peers and statefulswitchover based failovers for customer side peers substantiallyeliminates the need for service providers to upgrade customer side peersto run the same version of software which supports graceful restart asused on the core side peers. As a result, the benefits of gracefulrestart may be experienced by peers which support graceful restart evenwhen customer side peers undergo stateful switchover.

FIG. 3 is a diagrammatic representation of a router which is arranged tosupport both graceful restart and stateful switchover. When an activeroute processor 306 of a router 302 boots up, a Border Gateway Protocol(BGP) generally marks sessions associated with peers, as for examplepeer 314, that support stateful switchover. In one embodiment, markingsuch sessions generally entails marking substantially all sessions withpeers that are not currently arranged to support graceful restart as“stateful switchover” or “peer transparent restart” sessions. For allsessions associated with router 302 that are not marked as statefulswitchover sessions, the BGP will typically negotiate graceful restartextensions and provide support for a graceful restart based highavailability solution.

For stateful switchover sessions, when a standby route processor 310effectively boots up, and a transmission control protocol (TCP) hascreated states 322 which correspond to the stateful switchover sessionson active route processor 306, TCP informs BGP to initialize sessionstates 322 on standby route processor 310. In one embodiment, BGP willsubstantially only create a minimum set of states 322 on standby routeprocessor 310, and treat the stateful switchover sessions as“receive-only” sessions.

The BGP on active route processor 306 of peer 302 will generally receiveBGP messages from peer 314 and process the BGP messages. By way ofexample, the BGP on active route processor 306 may receive an openmessage from peer 314, and proceed to parse through the open message.The BGP on standby processor 310 will also receive the open message, butwill typically not send any message out to peer 314.

With reference to FIG. 4, a router which is arranged to effectivelyperform both graceful restarts and stateful switchovers will bedescribed in accordance with an embodiment of the present invention. Arouter 404 which includes an active route processor 408 and a standbyroute processor 412 is in communication with a graceful restart peer416, or a peer which supports graceful restart, and a statefulswitchover peer 420, or a peer which does not support graceful restart.Communication between router 404 and graceful restart peer 416 may besupported by a link 424, while communication between router 404 andstateful switchover peer 420 may be supported by a link 428. Gracefulrestart peer 416, in one embodiment, may be a core side peer whilestateful switchover peer 420 is typically a customer side peer, e.g., acustomer side BGP peer.

When router 404 fails or otherwise needs to be restarted, as for exampledue to a software upgrade, sessions between graceful restart peer 416and router 404 may be reestablished using a graceful restart. Sessionsbetween stateful switchover peer 420 and router 404 may effectively besustained using a stateful switchover process that enables a set ofstates, e.g., routing states, to be substantially recovered. A statefulswitchover process may include resending state updates from standbyroute processor 412 to stateful switchover peer 420. Active routeprocessor 408 may update standby route processor 412 with connectivityand management information which enables standby route processor 412 totake over the functions of active route processor 408 when active routeprocessor 408 fails. Once the failed route processor reboots, i.e., onceactive route processor 408 reboots, the failed route processor becomesthe new standby route processor while original standby route processor412 becomes the new active route processor. A synchronization processmay then occur in which the new active route processor synchronizesinformation with the new standby route processor.

In general, router 404 is arranged to perform a graceful restart withrespect to graceful restart peer 416, and to perform a statefulswitchover process with stateful switchover peer 420. It should beappreciated that stateful switchover peer 420 is generally any peerwhich either does not support graceful restart, or is configured todisable graceful restart. BGP creates, e.g., duplicates or mirrors, asubstantially minimum number of states associated with a sessionsbetween router 404 and stateful switchover peer 420 on standby routeprocessor 412. The duplicate or mirrored states, e.g., routing states,may be used to reestablish sessions between router 404 and statefulswitchover peer 420 when a stateful switchover process is used inresponse to a failover.

The steps associated with responding to a failure, or a planneddowntime, may be widely varied. FIG. 5 is a process flow diagram whichillustrates the steps associated with one method for effectivelyrestarting a router once a failure has occurred in accordance with anembodiment of the present invention. In other words, FIG. 5 is a processflow diagram which illustrates the steps associated with a failoverprocess that uses both graceful restart and a transparent failover suchas a stateful switchover. A process 502 of responding to a failurebegins at step 506 in which an event queue is processed to recreatestates. The event queue is maintained on a standby route processor ofthe router on which the failure has occurred, and is used to recreatestates associated with an active route processor when the states on theactive route processor are no longer available.

In one embodiment, the event queue is maintained on a standby routeprocessor and substantially continuously receives events from an activeroute processor. The events are used to recreate states associated withthe active route processor When a switchover occurs, the standby routeprocessor takes over and first processes substantially all events in theevent queue to bring the standby route processor up to speed, i.e., tosynchronize the standby route processor, with the state of the activeroute processor before a failure occurred.

After the event queue is processed, a transport layer (TCP) sends outpackets marked by BGP that have not been acked in step 510. In otherwords, the transport layer will send out outstanding packets that needto be sent out. As will be appreciated by those skilled in the art,outstanding packets are packets or data in a transport window that hadto be checkpointed because BGP marked a BGP protocol data link as onethat needed to be checkpointed.

Once the transport layer sends out packets marked by BGP that have notbeen acked, Keep Alive packets (Kas) are sent to stateful switchoverpeers in step 514. In step 518, sessions with graceful restart peers arereestablished using the standby route processor. The steps associatedwith reestablishing sessions with graceful restart peers are generallywell known to those skilled in the art.

Upon reestablishing sessions with graceful restart peers and effectivelyreceiving data from the graceful restart peers according to gracefulrestart procedures, the router reruns a best path algorithm to find thebest path among the paths available with BGP in step 520. Then, in step522, updates are resent to stateful switchover peers as well as gracefulrestart peers. The updates may include updates associated with new bestpaths through the network, as determined in step 520.

A “sent prefix” database is run through in step 522, and withdraws aresent out to stateful switchover peers if required. The “sent prefix”database, which is maintained on the standby route processor andcontains prefixes associated with update packets which have been sent bythe active router, is checked to identify substantially any missingprefixes, i.e., prefixes for which updates have not been sent after theswitchover. If it is determined that a particular prefix is missing, theindication is that a particular update packet has not been successfullysent before the switchover. As such, a withdraw is sent by the standbyroute processor.

After the “sent prefix” database is run through, the standby routeprocessor and the active route processor are synchronized in step 530.Synchronizing the route processors includes effectively rendering thecurrent standby route processor to be the new active route processor,while rendering the current active route processor to be the new standbyroute processor. The steps associated with one method of synchronizingthe route processors will be discussed below with respect to FIG. 6.After the current standby route processor and the current active routeprocessor are synchronized, the process of responding to a failure or adowntime is completed.

FIG. 6 is a process flow diagram which illustrates the steps associatedwith one method of synchronizing route processors in a router when astandby route processor effectively “comes up” or is otherwise activatedas a new active route processor in accordance with an embodiment of thepresent invention. A process 602 of synchronizing route processors on arouter begins at step 604 in which a connection request is accepted froma stateful switchover peer. Once the connection request is accepted, acorresponding connection is created on the active route processor, i.e.,the new active route processor, in step 608. Then, in step 610, aconnection is created on the standby route processor. In general, theconnection that is created on the standby route processor issubstantially the same as the connection created on the active routeprocessor.

After the connection is created on the standby route processor, datastructures in TCP and BGP are established on both the active routeprocessor and the standby route processor in step 618. Upon establishingthe appropriate data structures, a packet is received into the activeroute processor in step 622, and the received packet is mirrored on thestandby route processor in step 626. Once the received packet ismirrored on the standby route processor, then in step 630, the activeroute processor creates substantially all states associated with thepacket. The standby route processor then creates a substantially minimumnumber of required states in step 634. The states created by the standbyroute processor are generally a subset of the states created by theactive route processor. Upon processing protocol updates received frompeers, the active route processor may generate updates to be sent out tostateful switchover peers. Before sending out the updates the activeroute processor will generally checkpoint prefixes that are part of suchupdates, to form the sent-prefix database on the standby, in step 635.In the event that a failure of the active route processor occurs, thepresence of a substantially minimum number of required states enablesthe standby route processor to be used in lieu of the active routeprocessor to maintain connections. Once the substantially minimum numberof required states is created on the standby route processor and thesent-prefix database on the standby is formed, the process ofsynchronizing is completed.

FIG. 7 depicts a network device that is suitable for use in accordancewith an embodiment of the present invention. In one embodiment, anetwork device 1000 is a programmable machine that may be implemented inhardware, software or any combination thereof. A processor 1002 executescode stored in a program memory 1004. Program memory 1004 is one exampleof a computer-readable storage medium. Program memory 1004 may be avolatile memory. Another form of computer-readable storage mediumstoring the same codes would be some type of non-volatile storage suchas floppy disks, CD-ROMs, DVD-ROMs, hard disks, flash memory, etc. Acarrier wave that carries the code across a network is another exampleof a computer-readable storage medium.

Network device 1000 includes a packet memory 1008, and interfaces withphysical media via a plurality of network interfaces 1006. For example,one of network interfaces 1006 may couple to an optical fiber and mayincorporate appropriate physical and link layer functionality. Otherexamples of network interfaces include Ethernet interfaces, DSLinterfaces, Gigabit Ethernet interfaces, 10-Gigabit Ethernet interfaces,etc. As packets are received, processed, and forwarded by network device1000, they may be stored in a packet memory 1008. Network device 1000implements all of the network protocols and extensions thereof describedabove as well as the features provided by the present invention.

Although only a few embodiments of the present invention have beendescribed, it should be understood that the present invention may beembodied in many other specific forms without departing from the spiritor the scope of the present invention. By way of example, while statefulswitchover has been described as being used when a session is associatedwith a peer which does not support graceful restart, stateful switchovermay generally be implemented with respect to substantially any suitablepeer. Such peers may includes peers which support graceful restart,i.e., stateful switchover may be used with a peer which supportsgraceful restart.

Stateful switchover is one example of a peer transparent failover whichmay be used to enable a router to reestablish sessions with a peer whichdoes not support graceful restart. It should be appreciated that in lieuof stateful switchover, substantially any suitable peer transparentfailover may be used to reestablish sessions with a peer when a routerthat is in communication with the peer needs to be restarted.

While a router may include a separate active route processor and astandby route processor, a router may not necessarily include separateactive route and standby route processors. For example, a router mayinstead include an active stack of BGP and TCP, and a standby stack ofTCP and BGP on the same physical route processor.

Generally, the steps associated with the various methods and processesof the present invention may vary widely. Steps may be altered,reordered, removed, and added without departing from the spirit or thescope of the present invention. Therefore, the present examples are tobe considered as illustrative and not restrictive, and the invention isnot to be limited to the details given herein, but may be modifiedwithin the scope of the appended claims.

1. A method for restarting a network device, the network device having aplurality of route processors, the network device being arranged to bein communication with a plurality of peers within a network, theplurality of peers including a first peer and a second peer, the firstpeer being arranged to support graceful restart, the method comprising:performing a graceful restart with respect to the first peer; performinga peer transparent failover with respect to the second peer, including:processing an event queue associated with a standby route processor ofthe plurality of route processors to recreate at least one stateassociated with a session between the network device and the second peeron the standby route processor; identifying at least one send packetthat is to be sent on the standby route processor; and sending out adummy packet to the second peer using the standby route processor tosubstantially fill in for the at least one send packet; wherein thegraceful restart and the peer transparent failover are performed inresponse to downtime associated with the network device.
 2. The methodof claim 1 wherein performing the peer transparent failover furtherincludes: executing an algorithm, the algorithm being arranged toidentify a path through the network; and sending at least one update tothe second peer using the path.
 3. The method of claim 2 whereinperforming the peer transparent failover further includes: identifying awithdraw using a database associated with the standby route processor;and sending the withdraw when the withdraw is identified.
 4. The methodof claim 3 wherein performing the peer transparent failover furtherincludes: substantially synchronizing the standby route processor and anactive route processor of the plurality of route processors.
 5. Themethod of claim 4 wherein substantially synchronizing the standby routeprocessor and the active route processor includes: identifying thestandby route processor as a first route processor; identifying theactive route processor as a second route processor; creating aconnection on the first route processor; creating a connection on thesecond route processor that is substantially the same as the connectionon the first route processor; receiving a packet on the first routeprocessor; mirroring the packet on the second route processor; creatinga set of substantially all states associated with the packet on thefirst route processor; and creating a subset of the set of substantiallyall states on the second route processor.
 6. The method of claim 5wherein the subset of the set of substantially all states is asubstantially minimum number of required states.
 7. A device suitablefor use in a network, the device being arranged to be in communicationwith a first peer and a second peer, the first peer being arranged tosupport graceful restart, the device comprising: a plurality of routeprocessors; code devices that determine when the device is to berestarted; code devices that cause a graceful restart to be performedwith respect to the first peer when it is determined that the device isto be restarted; code devices that cause a peer transparent failover tobe performed with respect to the second peer when it is determined thatthe device is to be restarted, the code devices including code devicesthat cause an event queue associated with a standby route processor ofthe plurality of route processors to be processed to recreate at leastone state associated with a session between the device and the secondpeer on the standby route processor; code devices that cause at leastone send packet that is to be sent on the standby route processor to beidentified; and code devices that cause a dummy packet to be sent to thesecond peer using the standby route processor to substantially fill infor the at least one send packet; and a medium that stores the codedevices.
 8. The device of claim 7 wherein the code devices that causethe peer transparent failover to be performed further include: codedevices that cause an algorithm to be executed, wherein the algorithm isarranged to identify a path through a network that includes the device;and code devices that cause at least one update to be sent to the secondpeer using the path.
 9. The device of claim 8 wherein the code devicesthat cause the peer transparent failover to be performed furtherinclude: code devices that cause the standby route processor and anactive route processor of the plurality of route processors to besubstantially synchronized.
 10. The device of claim 9 wherein the codedevices that cause the standby route processor and the active routeprocessor to be substantially synchronized include: code devices thatcause the standby route processor to be identified as a first routeprocessor; code devices that cause the active route processor to beidentified as a second route processor; code devices that cause aconnection to be created on the first route processor; code devices thatcause a connection to be created on the second route processor that issubstantially the same as the connection on the first route processor;code devices that cause a packet to be received on the first routeprocessor; code devices that cause the packet to be mirrored on thesecond route processor; code devices that cause a set of substantiallyall states associated with the packet on the first route processor to becreated; and code devices that cause a subset of the set ofsubstantially all states to be created on the second route processor.11. The device of claim 10 wherein the subset of the set ofsubstantially all states is a substantially minimum number of requiredstates.
 12. A device suitable for use in a network, the device beingarranged to be in communication with a first peer and a second peer, thefirst peer being arranged to support graceful restart, the devicecomprising: a plurality of route processors; means for performing agraceful restart with respect to the first peer; and means forperforming a peer transparent failover with respect to the second peer,wherein the graceful restart and the peer transparent failover areperformed in response to a resetting process associated with the device,the means for performing the peer transparent failover including: meansfor processing an event queue associated with a standby route processorof the plurality of route processors to recreate at least one stateassociated with a session between the device and the second peer on thestandby route processor; means for identifying at least one send packetthat is to be sent on the standby route processor; and means for sendingout a dummy packet to the second peer using the standby route processorto substantially fill in for the at least one send packet.
 13. Thedevice of claim 12 wherein the means for performing the peer transparentfailover further include: means for executing an algorithm, thealgorithm being arranged to identify a path through the network; andmeans for sending at least one update to the second peer using the path.14. The device of claim 13 wherein the means for performing the peertransparent failover further include: means for substantiallysynchronizing the standby route processor and an active route processorof the plurality of route processors.